Question for someone who'd actually gotten a dojo Dialog to work on a XPage...

HCL Notes/Domino 8.5 Forum (includes Notes Traveler)

Subject: Question for someone who'd actually gotten a dojo Dialog to work on a XPage...

Feedback Type: Question

Product Area: Domino Server

Technical Area: Functionality

Platform: Windows

Release: 8.5.1

Reproducible: Always

- This has got to be something trivial. I've read how to do it, but it won't work for me.

- From the xpagesblog:

http://xpagesblog.com/xpages-blog/2010/4/10/xpages-compatible-dojo-dialog-reusable-component.html

I've tried the "ZetaOne" wrapper to move the dialog to the correct place in the DOM. When I do that, it gets an Exception that the id for the widget it's creating is already registered, and the dialog fails. I even put in a check for the dialog before calling the wrapper to run destroyRecursive, but that makes no difference. I consistently get an Exception and see no dialog.
The Exception doesn't appear until I click the button that should present the dialog, because the dialog doesn't exist until the button is clicked.
From what I understand of dojo dialogs, one makes div with an id, puts markup under that div to lay out the dialog, tells dojo to treat that div as a dialog by passing the id to dialog_create(), then one my use the id to get a reference to the dialog as needed. So if I change the id of the div (or remove it entirely), how do I get a reference to the dialog later?

- If I use the "ZetaOne" wrapper but change the ID, I get a blank dialog. It's got a title and a "X' to close it, but no content. I'm thinking this is because there's no longer a reference to the div that defines the content. The "X" also does nothing and I have to kill the window to "exit" the dialog.

- From Luc's post here I've also tried a plain dijit.Dialog() constructor. This creates the dialog just fine, using exactly the same ID that gets an exception above. But while I see the dialog and may interact with it, the "Add Comment" button does nothing but dismiss the dialog, just like Cancel. It never runs any CS or SS, no simple action, nothing, or at least a breakpoint in Firebug never stops in the CS button code, and an alert in the CSJS does not pop. Yet the code to dismiss the dialog, when the dialog button is clicked, is IN the CSJS. If it's not running that, how does it dismiss?

- In a comment on the Xpages Blog, "Dragon Chow" has the same issue on April 29. Buttons are not working in a dialog. The code (s)he presents there is similar to one of the many variants I've tried, except I'm using an id: instead of an url:. I also run this code on a button directly, instead of doing it on load, because a companion page to the above has a working sample of this dialog in action, and that sample calls this code on a button, then destroys the dialog when dismissed.

- I've actually tried it both ways. If I do addOnLoad, it gets an error on page load that that mll[x] is not a function. If I breakpoint in the onload function and single step I get no such error, but when the function exits the browser constantly shows the "busy" cursor and no buttons work anywhere. "Back" on the browser window itself does, so the browser isn't locked up. Just the CSJS appears to be.

- I have also captured the sample code from the working sample page, and the full HTML source of the working sample page, to use as a model. So far that's not been much. The sample runs, my code doesn't. Other than removing the partial refreshes, because I'm not using them, one of the many variants I've tried is identical to the sample, both with and without references to non-existent elements like editDocumentRegion. All variants of the "ZetaOne" wrapper produce the same id collision error.

- I'm thinking the straight create renders because the dialog is "outside" the DOM, so there's no collision, but it fails to run anything server-related because it's "outside" the DOM, and the XPage doesn't know what to do.

- I'm thinking the "ZetaOne" wrapper doesn't render because it's "inside" the DOM tree and there is a collision with the (dialog) div's ID attribute, but I don't know how to resolve that. I'm hoping since it is "inside" the DOM tree, server-side things will work, if I can only get to where the dialog is usable.

- Could someone who's done this successfully please toss me a bone?

Thanks for your time...

Feedback number DGIE86WKW5 created by ~Holly Zekhipisonnivu on 06/30/2010

Status: Open
Comments: THIS DOES NOT WORK: As always it randomly fails to trigger postSaveDocument. Once it fails, it won't run it again. This has plagued me from the very beginning, and still seems unresolvable.

1. Use the ZetaOne wrapper for dijit dialogs, reproduced here for simplicitly. I apologize to the original author for not having their name here.:

// com.ZetaOne.Widget.Dialog
dojo.provide('com.ZetaOne.widget.Dialog');
dojo.require('dijit.Dialog');
(function(){
dojo.declare("com.ZetaOne.widget.Dialog", dijit.Dialog, {
postCreate: function(){
this.inherited(arguments);
dojo.query('form', dojo.body())[0].appendChild(this.domNode);
},
_setup: function() {
this.inherited(arguments);
if (this.domNode.parentNode.nodeName.toLowerCase() == 'body')
dojo.query('form', dojo.body())[0].appendChild(this.domNode);
}
})
}());

2. Use this dialog_create:

/**
* Creates a dijit dialog box based on a div content
* based on working sample page at xpagesblog.com by Jeremy Hodge.
* @param id div identifier
* @param title1 What to put in the dialog title bar
*/
function dialog_create(id, title1) {
var dialogWidget=dijit.byId("dialog");
if(dialogWidget && dialogWidget.destroyRecursive) dialogWidget.destroyRecursive(false);
dialogWidget=new com.ZetaOne.widget.Dialog({
title: title1,
id: "dialog",
onCancel: function() {
this.destroyRecursive(false);
}
});
dojo.body().appendChild(dialogWidget.domNode);
dialogWidget.startup();
dialogWidget.show();
var editRegion=dojo.query('[id$="'+id+'"]')[0];
dojo.style(editRegion, { display: 'block' });
dialogWidget.containerNode.appendChild(editRegion);
}

Notable differences between this and the original XPages Blog working sample are:

- editRegion names the div on the custom control that defines the dialog layout. The name of the dialog itself ("dailog" in this instance) is a constant that doesn't matter as long as only one dialog at a time is ever presented. This dialog is created and destroyed on an as-needed basis, with differing content as required. The custom control itself is currently based on the XPages Sample as well, but due to Item 3 below, it can probably be straight HTML, but I only just got this working, so I haven't tried that.

- onCancel only destroys the dialog. It does nothing else with editRegion or refreshRegion.

3. DO NOT under any circumstances use <xp:eventhandler>!! Code runs from there just fine on the invoking button, but the dialog never waits for interaction. It loads and blasts right through to save and dismisses. Adding return in CSJS or nothing else seems to matter one whit, with respect to making it wait until the user is done before performing save.

Instead put all code in CSJS functions and use onclick="function call". This always waits for the user to get done before driving on, so the dialog works as expected.

This applies to the custom control containing the dijit dialog layout as well. If <xp:eventhandler> is used there, not a single action will ever take place. No CSJS, no simple actions, nothing at all. BUT if the code is put in a CS function and called via onclick="function name", then the CSJS runs fine as you please.

4. Since it's impossible to use <xp:eventhandler>, it's also impossible to use <xp:saveDocument> either on your dialog or on the invoking button. Fortunately the XPages Blog and Jeremy Hodge come to the rescue again. Use the "run server-side from the client" trick located here:

http://xpagesblog.com/xpages-blog/2010/4/15/programmatically-triggering-an-xpages-server-side-event-hand.html

to trigger server-side save. Here's what my dijit dialog's CSJS function looks like:

function dlgWFNSubmit() {
var xpAct=dojo.byId("#{id:xpAction}");
xpAct.value="WFN:"+dojo.byId("#{id:dlgWFComment}").value+"]";
executeOnServer("saveOnly", dojo.query('[id$="tktActions"]')[0].id);
var dialogWidget=dijit.byId("dialog");
if(dialogWidget && dialogWidget.destroyRecursive) dialogWidget.destroyRecursive(false);
}

The executeOnServer is verbatim from URL above, which does a <xp:saveDocument> with a partial refresh on the side.

- Don't know about anyone else, and I don't understand entirely why, but this does exactly what I want it to do:

1. Present a dialog in response to a button.

2. Capture simple input and put it in a known field.

3. Touch off save, including postSaveDocument.

4. Do this repeatedly.

Hope this helps someone. It's sure taken me enough weeks of face bashing.

I wouild also like to know, from the XPages Gurus, precisely why this works when other known solutions do not.